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(54) Ad hoc secure access to documents and services 



(57) A document server (1 02) residing on a network 
behind a firewall (1 1 2) provides secure access to docu- 
ments or services residing thereon. A first user (A) out- 
side the firewall communicates with the document serv- 
er (1 02) over an established first secure session to gen- 
erate a token in a database (124) of tokens on the doc- 
ument server. The first user (A) digitally signs the public 
key of a second user (B) and an identifier of the token. 



The first user transmits a URL token to the second user 
that identifies the location of the document (102) server 
and the token identifier. When the second user outside 
the firewall (112) redeems the URL token at the docu- 
ment server, the document server and the second user 
establish a second secure session. The document serv- 
er (102) authenticates the URL token against the sec- 
ond secure session before providing the second user 
with access to the document or service. 
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Description 



[0001] The present invention relates generally to a 
method and apparatus for providing secure access to 
documents or services stored on a network protected 
by a firewall to users located outside the firewall that are 
not registered users of the network. 
[0002] Cun-ently many documents and services 
stored behind firewalls of private networks are sought 
to be shared with users who do not have access to the 
private network (i.e., are not registered users on the pri- 
vate network). A private network is any network that re- 
stricts access to it at its gateways or individually at each 
machine. 

[0003] Generally, a network is coupled to other net- 
works through gateways. Afirewall is installed at a gate- 
way to prevent unauthorized access through the gate- 
way. For example, a private network may take the fomn 
of a corporate intranet that is coupled to a public network 
such as the Internet through a gateway. The gateway of 
the private network may have afirewall that checks mes- 
sages entering or exiting the private network. Messages 
will pass through the firewall only if they meet predefined 
security criteria (e.g., come from a specified address, 
are directed to specified ports, etc.). 
[0004] Accordingly, it would be desirable to provide a 
user registered on a private network with the ability to 
grant secure controlled access to users not registered 
a priori on the private network to documents and serv- 
ices stored behind the firewall of the private network. 
Such access would advantageously allow the user not 
registered on the private network access to Infomnation 
and services that are dynamic. 

[0005] In accordance with the invention there is pro- 
vided a method, system and article of manufacture 
therefor, for a first user to provide secure access to elec- 
tronic documents or services stored on a document 
server located on a networi< to a second user, where the 
f irst user is a registered user of the document server and 
the second user Is not a registered user of the document 
server, and where first user, the second user, and the 
document server have each associated therewith a pub- 
lic key that is associated with a corresponding private 
key. The method performed on the document server in- 
cludes: exchanging public keys with the first user to es- 
tablish a first secure session; receiving from the first us- 
er a request to list a file directory; authenticating the first 
user's access to the file directory using credentials pro- 
vided by the first user when the first secure session is 
established; transmitting to the first user a listing of the 
file directory over the first secure session; the listing 
identifying a set of paths to content available on the doc- 
ument server; exchanging public keys with the second 
user to establish a second secure session; receiving 
from the second user a request for access to selected 
content on the document server; the request for access 
including a token identifier that is recorded at the docu- 
ment server and associated with a path from the set of 



paths to the selected content available on the document 
server; authenticating the request for access using: (a) 
the public key of the second user received from the sec- 
ond user while establishing the second secure session, 
5 and (b) a digital signature signed using the private key 
of the first user that is a signed cryptographic digest of 
the public key of the second user and other information 
relating to the request for access to the selected docu- 
ment content on the document server (e.g., the token 
10 identifier, the path to the selected content, a creation 
date, access rights, etc.); providing the second user with 
access to the selected content over the second secure 
session If the request for access Is authenticated. 
[0006] In one embodiment, each public key is includ- 
15 ed as part of a digital certificate that Is held by each party 
(e.g., the first user, the second user, or the document 
server) holding the private key associated with that cer- 
tificate. 

[0007] These and other aspects of the invention will 
20 become apparent from the following description read in 
conjunction with the accompanying drawings wherein 
the same reference numerals have been applied to like 
parts and in which: 
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Figure 1 illustrates an operating environment for 
perfomning the present invention; 
Figure 2 illustrates one embodiment in which URL 
tokens may be issued from user A, who is an au- 
thorized user on the private network shown in Fig- 
ure 1 , to user B who is not; 

Figure 3 illustrates one manner for user A to gener- 
ate a digital signature of the URL token; 
Figure 4 illustrates one embodiment for cashing in 
an Issued URL token; and 

Figure 5 Illustrates one embodiment in which the re- 
quest for access to a document or service may be 
authenticated. 



[0008] Figure 1 illustrates an operating environment 
40 1 GO for performing the present invention. The operating 
environment includes a document server 1 02 that com- 
municates directly or indirectly over (wired or wireless) 
public networks and/or untrusted networks, such as the 
Internet 104, with user device A 106 and user device B 
45 108 (also referred to herein as user A and user B, re- 
spectively). The user devices 1 06 and 1 08 may be mo- 
bile or stationary computational devices, such as hand- 
held devices, computer laptops, desktops and servers. 
[0009] In one embodiment, the document sen/er 1 02 
50 communicates indirectly with the user devices 1 08 and/ 
or 1 08 through a gateway 11 0 of a private network 114 
(e.g., an intranet) protected by a firewall 112. in this or 
other embodiments, a proxy sender 116 (or proxy 116) 
may be used to filter communications to and from the 
55 document server 102. In yet another embodiment, the 
document server 1 02 communicates directly with devic- 
es 1 06 and/or 1 08 over trusted or untrusted networks. 
[0010] The operating environment 100 also includes 
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a public key infrastructure (PKI). In the PKI, typically a 
certificate authority 118 or a trusted third party is used 
to sign digital certificates 120, 132, and 134 Issued to 
the document server 1 02, user A of the device 1 06, and 
user B of the device 108, respectively. The public key 5 
infrastructure permits two parties to dynamically estab- 
lish secure communications with each other without ev- 
er having a prior relationship through the use of a digital 
certificate. 

[0011] Digital certificates may for example be in the 
form described by the ITU X.509 digital certificate stand- 
ard, alternatively, digital certificates may be in form de- 
scribed in the WTLS (Wireless Transport Layer Securi- 
ty) security layer of WAP (Wireless Application Protocol) 
or in the form of SPKI (Simple Public Key Infrastructure) 
certificates. 

[GDI 2] Altemative encryptions schemes besides RSA 
(Rivest-Shamlr-Adleman) public key encryption tech- 
nology may be used to carry out the invention, such as 
elliptic curve cryptography or the Digital Signature Algo- 
rithm (DSA) forming part of the U.S. Digital Signature 
Standard (DSS). 

[0013] One or more certificate authorities may be 
used in the operating environment 100. For example, 
the private network 11 4 may have its own certificate au- 
thority that services certificates issued to authorized us- 
ers of the network, or some or all of the parties (e.g., 
user A, user B, the document server) may obtain certif- 
icates from a recognized public certificate service bu- 
reau (e.g., Verisign®). Finally, it will be clear to one 
skilled in the art that as the document server recognizes 
entities to trust based on their keys, rather than who 
signed their digital certificates, and that arbitrary certif- 
icates, such as self -signed certificates (I.e., where the 
party to which the key pair belongs acts as its own cer- 
tificate authority), or even unsigned public keys In Iso- 
lation, may alternatively be used. 
[0014] When two parties (e.g., user A and the docu- 
ment server) exchange their public keys and combine 
them with their respective private keys, both parties can 
agree on a symmetric secret key for a particular com- 
munications session (I.e., a session key). The session 
key is used to encrypt and decrypt information transmit- 
ted between the parties over an insecure (i.e., untrust- 
ed) communication channel. This manner of defining a 
session key does not pemriit an eavesdropper to deduce 
the session key by observing the communication chan- 
nel over which the parties communicate. 
[0015] One protocol for transmitting data securely 
over an insecure communications channel in this man- 
ner Is defined in the Secure Socket Layer (SSL) proto- 
col, as published in "The SSL Protocol Version 3.0", dat- 
ed March 4, 1996. In an alternate embodiment the In- 
ternet Engineering Task Force (IETF) standard entitled 
Transport Layer Security (TLS), which is based on SSL, 
may also be used to establish a secure session over the 
Internet. TLS Is described In IETF RFC 2246. The SSL 
3.0 protocol and the TLS protocol, which are supported 
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by standard web browsers, are invoked as part of the 
HyperText Transfer Protocol (HTTP) using the "https" 
extension. 

[001 6] In accordance with one aspect of public key in- 
frastructures, the document sen/er 102, user A device 
1 06, and user B device 1 08 are adapted to generate dig- 
ital signatures of selected content. A digital signature is 
a signed cryptographic digest of the selected content us- 
ing a given private key. Anyone with the public key cor- 
responding to the given private key can verify the au- 
thenticity of the signed cryptographic digest. In accord- 
ance with another aspect of public key infrastructures, 
the document server 102, user A device 106, and user 
B device 108 are adapted to define a session key for 
each communication session (i.e., secure session) that 
are established between each other. 
[0017] In general, the document server Is adapted to 
provide client devices operated by users not registered 
on the document server (such as user B) with ad hoc 
secure access to documents or services behind a fire- 
wall. The client devices may be mobile devices such as 
PDAs (Personal Digital Assistants), smart phones, and 
laptops. The document server communicates seam- 
lessly with existing browsers operating on client devic- 
es, advantageously not requiring any custom software 
be installed on the client devices, firewalls, or proxy 
servers since any special operations are downloaded 
by the browser In real time to the client devices on an 
as needed basis. 

[0018] The document server 102 includes various el- 
ements that may be stored thereon or on one or more 
servers to which the document server 1 02 has commu- 
nicative access. In one specific embodiment, the docu- 
ment server 1 02 is a web serverthat has directories and 
files physically located on one or more computers with 
which the document server communicates and has ac- 
cess thereon. In this embodiment, user A's directories 
may, for example, exist on one or more machines 
mapped as directories on the document server 102. 
[0019] The elements of the document server 102 In- 
clude server scripts (e.g., active server pages (ASPs)) 
122, a token database 124, a document database 126, 
and an authorized user database 128. The server 
scripts 122 are scripts that are njn in response to https 
requests from clients such as user devices 106 or 108. 
The scripts may be run on the client or server machines 
to perform desired actions. The document database 1 26 
stores documents or document services (referred to 
herein together as content) accessible only to registered 
users of the private network 114, 
[0020] The token database 124 records Information 
relating to tokens issued to registered users of the pri- 
vate network 114. As described in detail below these to- 
kens may take different fomris. Depending on the partic- 
ular form, tokens issued that are recorded in the token 
database 124, such as token 125, may be associated 
with a token ID (identifier), a user name, a document or 
service path, access rights, and audit information. The 
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document or service path is the location at which an au- 
thenticated user may access documents or services in 
the document database 126. The audit information 
specifies information such as: when the token was is- 
sued, the duration the tol<en is valid, and whether the 
token is valid (e.g., whether it was revoked), and how 
the token was used (e.g., whether it was accessed, how 
many times it was accessed, etc.). Access rights specify 
infomiation such as: how the token may be used, the 
version of the document or service to which access may 
be given, and whether the token is delegable (i.e. , trans- 
ferable). 

[0021 ] By way of overview, an example scenario is de- 
scribed with reference to Figure 1 . User A operating the 
device 1 06 seeks to provide user B operating the device 
108 access to a document or service available behind 
the firewall 1 1 2 of the private network 11 4 to which user 
A is a registered user (e.g., has an account) and user B 
is hot. Thus, any attempted access by user A through 
the gateway 11 0 to the document server 1 02 is authen- 
ticated and may be automatically mapped to user A's 
settings in the private network 114 (e.g., user account, 
user privileges, user default directory, etc.). 
[0022] Initially, user Athrough device 1 06 establishes 
a first secure session with the document server 102 
through firewall 112 of gateway 110 and proxy 116 to 
access documents stored in the documents database 
126 to which user A has access. User A subsequently 
generates a URL (Unlfomi Resource Locator) token that 
embodies a unique token ID. Generally a URL consists 
of three fields: (a) a protocol field (e.g., https); (b) an 
address field of a host computer (e.g., within the DNS 
(Domain Name System)), and a path field (i.e., identifies 
a path to a file name or service). A digitally signed cryp- 
tographic digest (referred to below in Figure 3 as URL 
token signature 31 0) of at least the public key to whom 
the token is directed and other infomnation relating to 
the token (e.g., the token identifier, the path, access 
rights, creation date) (referred to below in Figure 3 as 
signature content 302), is transmitted to the document 
server 102 and associated in the token database 124 
with the unique token ID. 

[0023] The URL token is then transmitted by user A 
to user B, who is then free to request access to (i.e., 
redeem) the document or service identified by the token 
even though the document server is unaware of user B 
who is making the request for access. Advantageously, 
the URL token penrtits late binding so that the contents 
of the document or service are transf en-ed to recipients 
at the time they desire the content (e.g., when a URL 
link to the content is selected), ratherthan having to pro- 
vide a copy of the document or immediate access to the 
service at the time the information concerning the doc- 
ument or service is sent by a content provider (e.g., user 
A) to a specified recipient (e.g., user B). 
[0024] The access by user A and user B to the docu- 
ment server 102 is performed using the https protocol 
(or another protocol that requires authentication of both 



parties). As part of the https protocol, SSL connections 
are established between the user and the server. Also 
as described in detail below requests for browsing doc- 
uments or services on the server as well as requests for 
5 access to the documents or services using the token are 
in the form of a URL that is requested using the https 
protocol. 

[0025] When a request for a document or service is 
made by user B, the document server 1 02 authenticates 
10 user B 108 as part of setting up an SSL connection, mak- 
ing the public key of user B known to the document serv- 
er. The document server then authenticates the token 
ID included as part of the URL token using user A's pub- 
lic key (as long as user A is still an authorized user on 
15 the private network 114 - e.g., exists in authorized user 
database 128). 

[0026] Figure 2 Illustrates one ernbodiment in which 
URL tokens may be issued from user A, who Is an au- 
thorized user on the private network 114, to user B, who 
20 is not an authorized user on the private network 114. 
User A may begin either by communicating with the doc- 
ument server 1 02 or user B device 1 08 using URLs that 
invoke a conventional browser such as Microsoft® In- 
ternet Explorer or Netscape® Communicator. A URLse- 
25 lected on a user device may invoke scripts in server 
scripts 1 22 on the document server 1 02 that cause op- 
erations to be performed on the user device or at the 
document server. 

[0027] In one embodiment, communication starts by 
30 user A 1 06 establishing a secure session at 202 with the 
document server 102 (using for example SSL) after, for 
example, a URL requesting a listing of files or services 
on the document server is selected at user A. In this em- 
bodiment, the browser of user A begins by establishing 
35 a secure session between the gateway 110, the proxy 
server 116, and ultimately the document server 102 by 
tunneling through the firewall 11 2. One method for tun- 
neling through a firewall over an SSL connection is de- 
scribed by Ah Luotonen, in "Tunneling SSL Through a 
40 WWW Proxy", IETF. Internet- Draft, March 26, 1997, 
published on the Internet at http.//www.watersprings. 
org/pub/ld/draft-luotonen-ssl-tunneling-03.tx. Opening 
the secure session between user A 1 06 and the docu- 
ment server 102 results in the exchange of digital cer- 
45 tificates 132 and 120, respectively. 

[0028] Once the secure session is established and 
user A is authenticated as a registered user of the doc- 
ument sen/er, the request for the directory listing of files 
or services is received by the document sen/er at 204. 
50 The document server operating, for example, Micro- 
soft's Internet Information Server (IIS) maps the regis- 
tered user directly onto user A's domain account of the 
private networi< 114to provide user A with the same ac- 
cess privileges (i.e., rights and limitations) in the domain 
55 if user A were operating inside the firewall 112. Upon 
receiving the transmitted directory listing (i.e., a set of 
paths to documents or services to which user A has ac- 
cess) at 206, user A invokes a script for creating a URL 
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token for the selected document or service from the di- 
rectory listing. The script invoked may be stored on the 
script server 122 or altematively it may be recorded In 
cache on the user device 106. 

[0029] As part of creating the URL token, user A se- 
lects a path of a document or service from the set of 
paths received from the document server, at 208. The 
selected path of the document or service that the user 
A chooses to make available to user B is transmitted to 
the document server, at 21 0. Upon receipt of the select- 
ed path, the document server 120 creates a new entry 
In the token database with a unique token tD and the 
path of the selected document(s) or servlce(s), at 212. 
At 21 4, the document server transmits the unique token 
ID associated the token in the token database recording 
the selected path. Anytime before the URL token is 
signed at 21 8, user A 1 06 must receive digital certificate 
Infonnation (e.g., digital certificate 134) from user B at 
216. The digital certificate information must at a mini- 
mum include the public key of user B. 
[0030] Once the public key of user B is received by 
user A, user B's public key and other selected content 
(such as the token ID) is signed by user A using the dig- 
ital signature standard (DSS). Figure 3 illustrates one 
known manner of Implementing the DSS. In Figure 3, a 
token signature generator 300 produces a URL token 
signature 310 (i.e., a digitally signed cryptographic di- 
gest) for signature content 302 using user A's secret key 
308. The token signature generator includes a crypto- 
graphic hash function 304 and a signing box 306. One 
example of an cryptographic hash function 304, which 
has the properties of one-wayness (i.e., Irreversibility) 
and collision-resistance, Is the revised Secure Hash Al- 
gorithm (SHA-1) that is specified in the Secure Hash 
Standard (SHS) which generates 160-bit hash output 
305 (i.e., cryptographic digest or message digest) of 
message Input (e.g., signature content 302). The sign- 
ing box 306 in one embodiment performs the functions 
of the Digital Signature Algorithm (DSA). 
[0031] In one embodiment, the signature content 302 
Includes user B's public key 312, and other Infonmatlon 
relating to the token such as: a token ID 31 4 (transmitted 
at 212 in Figure 2), a document (or service) path 316 
(specified at 210 in Figure 2), and token rights 318 
(which may be specified at 21 0 along with the path) . 
The token rights 31 8 may be specified by user A anytime 
before signing the content and may for example Include 
an expiry date, the number of times the document may 
be cashed or the duration the service may be used. 
Such token rights may also specify whether the token 
may be assigned to another Individual, and billing infor- 
mation related to the digital property rights of the docu- 
ment or service. In another embodiment, the signature 
content includes only User B's public key 312 and the 
token ID 314. 

[0032] Referring again to Figure 2, once signed with 
the private key of user A, the URL token signature is 
transmitted to the document server at 220, and recorded 
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in the token database 124 at 222, at which point the se- 
cure session temnlnates at 224. Anytime after user A re- 
ceives the token ID, user A may transmit the URL token 
to user B at 226, at which point user B is notified of Its 
5 receipt at 228. The URL token may be transmitted to 
user B by either user A or the document server 102 ei- 
ther directly or Indirectly (e.g., IR link, email, SMS mes- 
saging, etc.). Once received, user B Is free to redeem 
th'e URL token at the document server 1 02 unless user 
A has removed the specified access or user A is no long- 
er an authorized user of the document server 102. 
[0033] In one embodiment, user A may provide to us- 
er B a URL token with the following general form: 

[Secure Socket Protocol]://[Gateway Address] / 
[Script]/[Token ID]. 

[0034] A specific example of this general form is: 



where "ValldateToken.asp?" is a script to be exe- 
cuted from the server scripts 122 and the number 
3243394924 Is the unique Token ID. 
[0035] It will be appreciated that additional Informa- 
tion such as the document or service name may be In- 
cluded as part of the URL token even though It may not 
be necessary for the document server 102 to uniquely 
Identify the document token. In addition, It will be appre- 
ciated that the script in the URL token need not be ex- 
plicitly recited as part of the URL but may be implied 
from the gateway address to which the URL is directed. 
[0036] Figure 4 illustrates one embodiment for cash- 
ing in an issued URL token. Initially, user B 108 invokes 
the caching in of a URL token by selecting it at 402, by 
either clicking on It as a hot link or loading it in a brows- 
er's address bar on the device 108, for example. This 
causes the browser to begin establishing a secure ses- 
sion with the document server 1 02 at 404, which In turn 
results in the exchange of certificates 134 and 120, re- 
spectively. 

[0037] Subsequent to establishing the secure session 
or as part of establishing the secure session, user B 
transmits the URL token to the document server at 406. 
Forming part of the URL token is a script identifier and 
a token identifier. The script identifier is used to invoke 
a script (or program) from the server scripts 122 that will 
execute instructions to identify a token in the token da- 
50 tabase 124 that corresponds to the unique token Iden- 
tifier forming part of the URL token and ensure the token 
Is still valid (I.e., has not been revoked) at 408. 
[0038] Once the token Is identified, the certificate of 
the user who created the token is validated against the 
55 database of authorized users 1 28 , at 409. The user who 
created the token Is recorded In the token database with 
the token. If creator of the token is not an existing au- 
thorized user then the token is deleted or made inacces- 
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sible and user B is notified that the URL token is non- 
redeemable. Subsequently, using the infomnation in the 
identified token, the script then authenticates the token 
content using the public key of user B at 410 obtained 
while establishing the secure session (e.g., SSL con- 
nection) at 404. 

[0039] If (a) the signature content of the token can be 
authenticated, (b) the access rights or audit information 
of the token indicates that user B continues to have ac- 
cess (e.g., access was not revoked by user A, or the 
number of times or duration it was accessed was not 
exceeded, or the token expiry date has not past), and 
(c) user A is still an authenticated user at the document 
server, then the document is retrieved or the service is 
provided from the document database 126 to user B at 
412 and 414, respectively. Subsequently, access right 
or audit information is updated in the token in the token 
database to reflect the access made by the user and/or 
billing imposed on the user, at 416. User B is notified 
upon receipt of the document or service over the secure 
session at 41 8 and once transmission completes the se- 
cure session is closed at 420. 

[0040] Figure 5 illustrates one embodiment in which 
the request for access to a document or service is au- 
thenticated at 41 0 in Figure 4. In Figure 5, a URL token 
authenticator 502 is shown which processes the signa- 
ture content 504 using the irreversible hash function 304 
(shown in Figure 3) to produce hash output 505 (i.e., 
cryptographic digest). In each instance the signature 
content 302 and the signature content 504 are assem- 
bled, the public key of user B is obtained directly from 
user B and is not recorded as part of the token database 
124. 

[0041] The hash output 505 and the URL token sig- 
nature recorded in the token database are then run 
through a checking box 506 to verify the authenticity of 
the signature content 504 using user A's public key 508 
that forms a key pair with user A's private key 308 
(shown in Figure 3). The output of the authenticator is 
an ok signal 510 if the signature content 504 is identical 
to the signature content 302 (shown in Figure 3) that 
was used to produce the URL token signature 31 0; oth- 
erwise, the output of the authenticator is a not ok signal 
512. 

[0042] Advantageously, URL tokens provide an ad 
hoc method for establishing secure access to user B to 
documents or services available on the document serv- 
er without the document server having prior knowledge 
of user B. Also, this relationship is seamlessly managed 
without involvement from user B, by not requiring prior 
registration of user B as a registered user on the docu- 
ment server or in the private network 114. In addition, 
URL tokens advantageously provides user B with con- 
tinuous access to documents or services that change 
dynamically over time (e.g., a calendar, or tax process- 
ing service), rather than a snapshot of a document is- 
sued or service releases at a particular point in time. 
[0043] Those skilled in the art will appreciate that the 



embodiment described in section D above may be mod- 
ified in a variety of ways as described below while 
achieving the similar or additional advantages de- 
scribed above. In addition, the sequence or organization 
5 of actions illustrated in the Figures are not intended to 
limit but depict one of many possible sequences in which 
the present Invention may be carried out. 
[0044] Referring to the arrangement shown in Figure 
2, the document server 102 and user A 106 may alter- 
to natively open and close a secure communication chan- 
nel to perform the limited acts 202, 204, 206, and 224 
before ever receiving certificate information (e.g., digital 
certificate 134) from user B at 216 and/or before ever 
receiving the signature of the URL token at 220. Subse- 
ts quently, user A 1 06 signs tbe U RL token and communi- 
cates it to user B 108. In this embodiment, the unique 
token ID is provided by the document server along with 
the directory listing at 206 or generated by user A (e.g., 
using a range of token identifiers pre-issued by the doc- 
20 ument server). 

[0045] At a later point in time, another secure session 
may be established between the document server 102 
and user A 1 06 at which point user A transmits to the 
document server signature of the URL token and its as- 
25 sociated unique token identifier. Alternatively the signa- 
ture of the URL token may be included as part of the 
URL token transmitted to user B at 226. In this alternate 
embodiment, the URL token would include in addition 
to the token identifier information that would have oth- 
30 erwise have been transmitted at 220 to be associated 
with the token identifier in the token database 1 24 such 
as the URL signature, the document path, the document 
rights issued. This infomnation can all be verified by the 
document server upon receipt from user B by adding the 
35 information to the signature content 302 and 504 (shown 
in Figures 3 and 5, respectively). 
[0046] For example in one alternate embodiment, us- 
er A may provide to user B a URL token having the fol- 
lowing general form: 

40 

[Secure Socket Protocol] ://[Gateway Address] / 
[Script] / [Signature] / [Rights] / [Document Path]/ 
[Token ID]. 



45 [0047] The rights field may contain for example the 
following information: (a) the expiry date of the token; 
(b) the number of times the token can be cashed; (c) if 
the document token can be passed (i.e., delegated) to 
another user; (d) charging and pricing information (e.g., 

50 specified for example using the ContentGuard® digital 
rights language XrML 2.0); (e) versions that can be ac- 
cessed; (f) usage time limit; (g) the issue date. 
[0048] In this embodiment user B presents the URL 
token signature at the time the token Is redeemed be- 

55 cause the token signature is not stored in the token da- 
tabase atthe document server. The advantage of having 
user A provide the URL token signature to user B as part 
of the URL token is that: (a) user B is given the ability 
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to present the URL token signature to the document 
server, thereby not permitting the document server to 
claim that user A did not actually issue the token; (b) 
user B is given the ability to construct a delegation cer- 
tificate to delegate the token to another user (assuming s 
such rights were granted by user A), and (c) user B is 
protected from non-repudiation from user A (i.e., user A 
cannot claim that someone else issued a token in user 
A's name). 

[0049] Alternatively, as described in section D above, 
the URL token signature is stored in the token database 
and thus not required to be (but may be) included as 
part of the URL token. In yet another embodiment, user 
A only signs user B's public key (i.e., the signature con- 
tent 302 is made up of a minimum of user B's public 
key). In this alternate embodiment, the token database 
stores the information (e.g., access rights, authorized 
user, document path, audit information, etc.) of the doc- 
ument token and the cryptographic digest of user B's 
public key. This embodiment assumes that anything 
stored in the token database is secure and reflects user 
A's actual intentions as communicated by user A during 
a secure session with the document server. 
[0050] No matter which embodiment, the document 
server must have access to or be able to reconstruct all 
the information user A used in constructing the token (e. 
g., the access rights) before giving access to the docu- 
ment or sen/ice to user B, that infonnation must be sent 
to the document server at some point by user A (e.g, 
when the token is registered), or presented by user B 
when the token is cashed (i.e., exercised or redeemed). 
The reason the document server has to be able to re- 
construct all the information used by user A in making 
the token is that it must be able to create a bit-for-bit- 
identical copy of the infonnation used to produce the 
cryptographic digest 505 (shown in Figure 5), in order 
to verify the URL token signature 31 0 of user A, thereby 
authenticating the public key of user B and other addi- 
tional information included as part of the signature con- 
tent 504 used to produce the cryptographic digest (e.g., 
the token identifier, a creation date, access rights, etc.). 
[0051] In addition, user A may provide user B along 
with the URL token (at 226 shown in Figure 2) and to 
the document server along with signature of the URL 
token (at 220 shown in Figure 2) a signed or unsigned 
cryptographic digest of the content or part of the content 
of the selected document or service (i.e., content di- 
gest). The advantages of specifying a content digest is 
twofold: First, providing the content digest to user B al- 
lows user B to verify the document or service it receives 
from the document server (at 41 8 shown in Figure 4) is 
that what user A intended user B to receive when user 
A issued the URL token to user B. 
[0052] Second, providing the content digest to the 
document server permits user A to specify to the docu- 
ment server that user B's access to the document or 
service is limited to particular states of the document or 
service (e.g., prerelease versus released) or that access 
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to the document or service include or exclude certain 
elements (i.e., early, late, or select binding of the docu- 
ment or service referenced in the URL token to the doc- 
ument content on the document server). 
[0053] In one embodiment, the content digest may be 
included with access rights information specified in the 
signature content 302 (shown in Figure 3). For example, 
the access rights Information may include: a digest of 
the current contents of a file representing the selected 
document or service, or a version number that indicates 
a particular state of the file at a particular point in time 
as maintained by a version control system operating on 
the document server. The version number may repre- 
sent, for example, the current version, a past version, 
or a future version of the selected document or service. 
[0054] In yet a further embodiment, the document 
server may be used to distribute secure access to doc- 
uments and services using the URL tokens by email to 
recipients whose public keys are known. 
[0055] In yet another embodiment, user A is provided 
mechanisms for audit and revocation (or modification) 
of access to issued URL tokens. That is, user A can ac- 
cess at any time the token database 124 using scripts 
in the server scripts 122 using a browser. Browsing the 
token database permits user A to Identify which tokens 
have been redeemed as well as other audit information 
such the frequency a token is redeemed, the last time It 
was redeemed, the duration a token is redeemed (e.g., 
with a sen/ice). Browsing the token database also per- 
mits user A to revoke issued URL tokens or refresh ex- 
piry information of Issued URL tokens. 
[0056] In one embodiment, user A and user B estab- 
lish a secure session with the document server by per- 
forming the following acts: (1 ) the gateway 110 opens a 
socket on a selected port to wait for a connection from 
the proxy 1 1 6; (2) the gateway 110 opens a socket on a 
different or the same port to wait for connections from a 
user device; (3) the proxy 116 connects to the gateway 
1 1 0 on a selected port via the firewall proxy 1 1 2; (4) the 
gateway 1 1 0 verifies the proxy's internet address Is val- 
id; (5) the user device connects to the gateway 11 0 by 
establishing an SSL connection with the document serv- 
er 102; (6) the gateway 110 directs data received from 
the user device to the proxy 116 and the proxy 116 di- 
rects the data to the document server 1 02; (7) the proxy 
1 1 6 directs data received from the document server 1 02 
to the gateway 110, and the gateway 1 1 0 directs the data 
back to the user device; (8) acts (6) and (7) are repeated 
while the user device is communicating with the docu- 
ment server 

[0057] To recapitulate, the present invention permits 
ad hoc secure access to specific documents or services 
stored behind a firewall without compromising security. 
This permits authorized users of a secure network (e.g., 
domain) to share specifically identified documents and 
or services (I.e., on a transaction by transaction basis 
or per-issue basis) only available to the authorized users 
behind the firewall of the secure network with third par- 
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ties who re not authorized users of the secure network. 
Access to the documents or sen/ices is actively man- 
aged by the document server and the authorized users 
by providing access to the secure network's documents 
or services whenever necessary via the token database, 
thereby providing a mechanism for reviewing monitor- 
ing, and revoking such access (e.g., on demand, after 
a period of time, after a predefined number of accesses, 
or subject to other predefined conditions). 
[0058] Additional information concerning token-ena- 
bled mobile computing devices is further described In 
U.S. Patents No. 5,862,321 and 6,144,997. 
[0059] Any resulting program(s), having computer- 
readable program code, may be embodied within one 
or more computer-usable media such as memory devic- 
es or transmitting devices, thereby making a computer 
program product or article of manufacture according to 
the invention. As such, the tenns "article of manufac- 
ture" and "computer program product" as used herein 
are intended to encompass a computer program exist- 
ent (permanently, temporarily, or transitorily) on any 
computer-usable medium such as on any memory de- 
vice or in any transmitting device. 
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A method for a first user to provide secure access 
to electronic documents or services stored on a 
document server located on a network to a second 
user, where the first user is a registered user of the 
document server and the second user is not a reg- 
istered user of the document server, and where both 
the first user, the second user, and the document 
server have each associated therewith a public key 
that is associated with a corresponding private key, 
the method perfomned on the document server 
comprising: 

exchanging public keys with the first user to es- 
tablish a first secure session; 
receiving from the first user a request to list a 
file directory; authenticating the first user's ac- 
cess to the file directory using credentials pro- 
vided by the first user when the first secure ses- 
sion Is established; 

transmitting to the first user a listing of the file 
directory over the first secure session; the list- 
ing identifying a set of paths to content availa- 
ble on the document server; 
exchanging public keys with the second user to 
establish a second secure session; 
receivingfrom the second user a request for ac- 
cess to selected content on the document serv- 
er; the request for access including a token 
identifier that is recorded at the document serv- 
er and associated with a path from the set of 
paths to the selected content available on the 
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document server; 

authenticating the request for access using: (a) 
the public key of the second user received from 
the second user while establishing the second 
secure session, and (b) a digital signature 
signed using the private key of the first userthat 
is a signed cryptographic digest of the public 
key of the second user and other information 
relating to the request for access to the select- 
ed document content on the document server; 
and 

providing the second user with access to the 
selected content over the second secure ses- 
sion if the request for access is authenticated. 

The method according to claim 1 , further compris- 
ing: 

receiving from the first user a request to create 
a token that is associated with the path to the 
selected content available on the document 

server; 

creating the token in a database of tokens on 
the document server; the token having associ- 
ated therewith the token Identifier; and 
transmitting to the first user over a secure ses- 
sion the token identifier that uniquely identifies 
the token in the token database. 

The method according to claim 2, further compris- 
ing: 

receiving from the first user over the first secure 
session the path from the set of paths Identify- 
ing selected content available on the document 
server; 

transmitting to the first user the token identifier 
over the first secure session; the token identifi- 
er being associated with the path to the select- 
ed content available on the document server; 
and 

receiving from the first user over the first secure 
session the digital signature of the signed cryp- 
tographic digest of the public key of the second 
user and the token identifier. 

. The method according to claim 2 or claim 3, receiv- 
ing from the first user over a third secure session 
the digital signature of the signed cryptographic di- 
gest of the public key of the second user and the 
other infomnation relating to the request for access 
to the selected document content on the document 
server. 

The method according to any of claims 2 to 4, 
wherein the other information relating to the request 
for access to the selected document content on the 
document server includes one or more of the token 
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identifier a creation date of the token, access rights 
to the selected content, all or portions of the select- 
ed content, and a version number of the selected 
content. 

5 

The method according to any of the preceding 
claims, wherein the document server is located on 
an Intranet protected by a firewall and wherein the 
first secure session and the second secure session 
tunnel through the firewall. io 

A document server for performing a method In 
which a first user provides secure access to elec- 
tronic documents or services stored on the docu- 
ment server located on a network to a second user, is 
where the first user is a registered user of the doc- 
ument server and the second user Is not a regis- 
tered user of the document server, and where both 
the first user, the second user, and the document 
server have each associated therewith a public key 20 
that is associated with a corresponding private key, 
the document server comprising: 

a memory for storing instructions; and 
a processor coupled to the memory for execut- 25 
ing the Instructions of the document server; the 
processor in executing the instructions: 

exchanging public keys with the first user 
to establish a first secure session; 30 
receiving from the first user a request to list 
a file directory; authenticating the first us- 
er's access to the file directory using cre- 
dentials provided by the first user when the 
first secure session is established; 35 
transmitting to the first user a listing of the 
file directory over the first secure session; 
the listing Identifying a set of paths to con- 
tent available on the document server; 
exchanging public keys with the second 40 
user to establish a second secure session; 
receiving from the second user a request 
for access to selected content on the doc- 
ument server; the request for access in- 
cluding a token identifier that is recorded at ^5 
the document server and associated with 
a path from the set of paths to the selected 
content available on the document server; 
authenticating the request for access us- 
ing: (a) the public key of the second user 50 
received from the second user while .estab- 
lishing the second secure session, and (b) 
a digital signature signed using the private 
key of the first user that is a signed crypto- 
graphic digest of the public key of the sec- ss 
ond user and other Information relating to 
the request for access to the selected doc- 
ument content on the document server; 



and 

providing the second user with access to 
the selected content over the second se- 
cure session if the request for access is au- 
thenticated, 

8. A server according to claim 7, the server being 
adapted to carry out a method according to any of 
claims 1 to 6. 

9. A computer program product storing program code 
for implementing a method according to any of 
claim 1 to 6. 
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(54) Ad hoc secure access to documents and services 



(57) A document server (1 02) residing on a network 
behind a firewall (1 1 2) provides secure access to docu- 
ments or services residing thereon. A first user (A) out- 
side the firewall communicates with the document serv- 
er (1 02) over an established first secure session to gen- 
erate a token in a database (124) of tokens on the doc- 
ument server. The first user (A) digitally signs the public 
key of a second user (B) and an identifier of the token. 



The first user transmits a URL token to the second user 
that identifies the location of the document (1 02) server 
and the token identifier. When the second user outside 
the firewall (112) redeems the URL token at the docu- 
ment server, the document server and the second user 
establish a second secure session. The document serv- 
er (102) authenticates the URL token against the sec- 
ond secure session before providing the second user 
with access to the document or service. 
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